Peter Powers
Terrorists of Dimensions
Electric Monkey Overlords
80
   |
Posted - 2012.05.15 11:38:00 -
[1] - Quote
CCP Seagull wrote:
Question 1: If every player can access CREST stuff through your beta integrations, well, then that's a public release of CREST rather than a beta. Do you guys have some suggestions on how to restrict access so that we don't release access for every player, but you guys can still try things out in a sensible way? Would it for example make sense if you supplied a list of user accounts that you'd like to be able to test CREST from? And then only characters on those accounts would be able to get access tokens?
that would be totally fine with me.
another option would be a sisi rollout. this would be kinda public too, but people wouldn't be working with live data. This would help both sides (you and us) to collect a bit of data on a more realistic usage scale (if we can gather enough users to try it out)
CCP Seagull wrote:
Question 2: When it comes to the user experience in applications, we're in for a bit of an interesting ride, as users will have to deal with 3 different API authentication methods: Old API keys, Customizable API keys, and then CREST application permissions. Do any of you have thoughts on how you would handle this? Are you thinking to do optional CREST authentication in addition to the API keys for example? We'd like a better idea of this, so that we can figure out how to best spend our efforts in smoothing the transition.
My stance on this is:
Old API Keys: i don't support 'em anymore, and i believe most other apps have switched too.
Crest Auth: we are speaking about the OAuth2 approach here, right? this will be my preferred way of identifying users as soon as its up and running.
Customizeable Keys: generally speaking of Auth API keys where never a good way to auth someone, so this "option" with all the tricks that needed to be done to be sure that the key owner owns the account will be dropped by my apps asap.
Since there is still a need for the keys though, i've looked into a few ideas.
There are a few options on how to migrate, and it depends a lot on what you guys are going todo.
For example one option that involves more work on your end, but would be very nice for the user would be that the OAuth part allows to give access to specific keys through Crest for an application, meaning If i auth through oauth and allow a specific application the right "retrieve key x", and then through crest could get this key so i can use it to access the old API, this would make transition very smooth. But i kinda doubt it fits in your timeframe to do such thing?
One of the things on my private todo list is to create a "Proxy" which accesses the old API but provides the information in CREST style, allowing apps to migrate fully to one access library, and to develop future applications without taking too much care about the legacy API. Now if you cant/wont do the feature i mentioned earlier, one of the services i could provide would be an Authed key storage that works together with that Proxy, so people don't have to enter their custom keys everywhere - however, that will always have the user-trust-issue, so having taken care of OAuth to customkey on your side would take alot of problems out for us app developers.
chat me up if you want more input on any of my suggestions,
regards,
PP |
Peter Powers
Terrorists of Dimensions
Electric Monkey Overlords
81
|
Posted - 2012.05.24 14:45:00 -
[2] - Quote
CCP Nullarbor wrote:I want to bump this thread with another question, from the current API what would be your priority order for porting them over to CREST? In particular highlight any where having read capability for data already exposed might be super beneficial.
most api pages are only relevant in package with a few others.
the priority put on 'em also depends alot on the usecase.
i'll see if i can compile you such list by my usecases during the weekend,
but this will mostly benefit a special subgroup of devs and not everyone,
since for example i wont care about factional warfare stuff, however
someone doing that would probably put those pages on top of the list.
|